Description

Security hardening and performance optimization across the Ledger Monitor and Transaction Signer modules. Implements the findings from the existing audit report into actionable code, adds cryptographic signature verification with replay protection, wires rate limiting into the app, and promotes raw SQL indexes into a tracked migration.

Closes #911
Closes #912
Closes #913
Closes #914

Changes proposed

What were you told to do?

• [Backend] Conduct security audit on Ledger Monitor #911: Conduct a security audit on Ledger Monitor and implement remediation
• [Backend] Implement rate limiting for Transaction Signer #912: Implement rate limiting for Transaction Signer
• [Backend] Add cryptographic signature verification to Transaction Signer #913: Add cryptographic signature verification to Transaction Signer
• [Backend] Optimize SQL queries in Transaction Signer #914: Optimize SQL queries in Transaction Signer

What did I do?

#911 - Ledger Monitor Security Hardening (ledger-monitor-security.js)

• Created backend/src/lib/ledger-monitor-security.js with: validatePaymentRecord (validates Stellar address format, positive finite amount, valid asset code, memo byte length, future-timestamp detection), sanitizePaymentMetadata (allowlist-based key filter, value truncation, drops nested objects), auditPaymentAnomaly (structured warning events for large amounts, memo control chars, stale payments), isValidTransactionHash (validates Horizon-returned hashes before DB writes)
• Integrated into horizon-poller.js: replaced loose field-presence guard with validatePaymentRecord, called auditPaymentAnomaly on every payment, added isValidTransactionHash guard before the duplicate-tx check, wrapped all metadata DB writes with sanitizePaymentMetadata

#912 - Rate Limiting Wired into App (app.js)

• Imported createTransactionSignerMiddlewares and handleVerifySignature from transaction-signer.js
• Registered POST /api/verify-signature with burst + standard rate limiters using Redis when available

#913 - Cryptographic Signature Verification (transaction-signer.js)

• Created backend/src/lib/transaction-signer.js wrapping verifyTransactionSignature from stellar.js with: validateTxHash (rejects non-64-hex inputs), in-process replay cache (5-min TTL, 10k cap, LRU eviction), structured audit logging, createTransactionSignerMiddlewares and handleVerifySignature Express route handler

#914 - SQL Indexes Migration (migrations/20260530000000_transaction_signer_indexes.js)

• Promoted raw SQL from backend/sql/migrations/20260529_transaction_signer_performance_indexes.sql into a tracked knex migration with up/down
• 7 indexes all created CONCURRENTLY IF NOT EXISTS: merchant+deleted+created, status+deleted+created (partial pending), id+deleted, status+tx_id (partial pending+null), merchant+status+created, recipient+asset+created, unique tx_id

Check List (Check all the applicable boxes)

• My code follows the code style of this project.
• This PR does not contain plagiarized content.
• The title and description of the PR is clear and explains the approach.
• I am making a pull request against the main branch (left side).
• My commit messages styles matches our requested structure.
• The implementation was reviewed and confirmed to work as intended.
• I am only making changes to files I was requested to.

Screenshots / Validation Evidence

• validatePaymentRecord rejects malformed Stellar addresses, non-finite amounts, invalid asset codes, oversized memos, and future-dated timestamps before any network call
• sanitizePaymentMetadata strips all non-allowlisted keys and truncates values over 500 chars, applied to underpayment and overpayment DB update paths
• verifyTransactionSignatureSecure returns replay: true on duplicate hash within TTL window
• POST /api/verify-signature returns 429 after burst threshold with X-RateLimit-* headers
• Migration indexes use CONCURRENTLY IF NOT EXISTS, safe to run on a live database